Point the README at 1.0-alpha (#379 follow-up) - #383

Renaming the C link names orphans every pg_proc row that recorded the old ones.
Replacing only the shared library, which is what a package upgrade does, leaves
the extension inert rather than degraded: reading an existing columnar table
fails with "could not find function columnar_handler", and so does creating a
new one. jdatcmd measured this on commandprompt#389.

There was also no way out. default_version was still 1.0-dev, so ALTER EXTENSION
pgcolumnar UPDATE had nothing to run, and the only remaining route was DROP
EXTENSION CASCADE, which takes the user's tables with it. v1.0-alpha shipped
carrying the old link names, so this is a live install base, not a hypothetical.

My error in the first version of this PR was reading "no upgrade scripts exist"
as "every install is fresh". It means the opposite. With no upgrade script an
existing install has no way to repair itself.

So:

  default_version           1.0-dev -> 1.0-alpha
  pgcolumnar--1.0-dev.sql   renamed to pgcolumnar--1.0-alpha.sql
  new                       pgcolumnar--1.0-dev--1.0-alpha.sql

The upgrade script is 27 CREATE OR REPLACE FUNCTION declarations covering 26
distinct link symbols, vacuum_sorted having two overloads. CREATE OR REPLACE
keeps each function's OID, so the CREATE ACCESS METHOD binding and every
dependency survive and only prosrc moves. No signature, permission, catalog or
on-disk format change.

The declarations are lifted verbatim from the install script rather than
retyped, so the two cannot drift, and the generator refuses to emit anything if
a link name still lacks the new prefix.

This also makes SELECT extversion report 1.0-alpha, matching VERSION. That
contradicts a sentence in my open commandprompt#383, which I will update rather than leave
wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Renaming the C link names orphans every pg_proc row that recorded the old ones.
Replacing only the shared library, which is what a package upgrade does, leaves
the extension inert rather than degraded: reading an existing columnar table
fails with "could not find function columnar_handler", and so does creating a
new one. jdatcmd measured this on commandprompt#389.

There was also no way out. default_version was still 1.0-dev, so ALTER EXTENSION
pgcolumnar UPDATE had nothing to run, and the only remaining route was DROP
EXTENSION CASCADE, which takes the user's tables with it. v1.0-alpha shipped
carrying the old link names, so this is a live install base, not a hypothetical.

My error in the first version of this PR was reading "no upgrade scripts exist"
as "every install is fresh". It means the opposite. With no upgrade script an
existing install has no way to repair itself.

So:

  default_version           1.0-dev -> 1.0-alpha
  pgcolumnar--1.0-dev.sql   renamed to pgcolumnar--1.0-alpha.sql
  new                       pgcolumnar--1.0-dev--1.0-alpha.sql

The upgrade script is 27 CREATE OR REPLACE FUNCTION declarations covering 26
distinct link symbols, vacuum_sorted having two overloads. CREATE OR REPLACE
keeps each function's OID, so the CREATE ACCESS METHOD binding and every
dependency survive and only prosrc moves. No signature, permission, catalog or
on-disk format change.

The declarations are lifted verbatim from the install script rather than
retyped, so the two cannot drift, and the generator refuses to emit anything if
a link name still lacks the new prefix.

This also makes SELECT extversion report 1.0-alpha, matching VERSION. That
contradicts a sentence in my open commandprompt#383, which I will update rather than leave
wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…iew)

Reviewing jdatcmd's commandprompt#392 turned up a second copy of the instruction I rewrote
in docs/installation.md, 85 lines below the paragraph that PR fixes.

limitations.md said the pre-release ships no ALTER EXTENSION UPDATE scripts,
which this branch makes false, and then told the reader they can replace the
shared library and restart without one. That is precisely the sequence that
leaves the extension inert. It then pointed at DROP EXTENSION, which takes the
user's columnar tables with it.

A user who hits the broken state and follows the status badge lands on that
page, so it was the worst remaining copy.

The paragraph now states that replacing the library is not sufficient on its
own, gives the command, explains why an un-updated catalog fails and with which
error, and says plainly that the data is untouched. The DROP EXTENSION paragraph
is scoped to a build no upgrade script covers, and says it is not the remedy for
this case.

I missed this in commandprompt#383 and again when I rewrote installation.md. Sweeping for a
second copy is the step I skipped both times.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The release-status page said no release was tagged (#383 follow-up)